An important feature of any computer system is the interface between the computer and the human operator. The commercial success or failure of computer systems often is due in a large part to the ease with which a human operator can use the system. An example of such a success is the Macintosh (trademark of Apple Computer Inc.) line of personal computers. The Macintosh line of personal computers is successful primarily because the components and interaction techniques used to complete tasks on the computers are very consistent throughout the product line. In addition, the concept of a "desktop" environment is depicted graphically in a meaningful manner, making common software components such as windows and icons easy to comprehend. Users are much more apt to understand how to complete a task if the same user interface components and techniques are repeated in each software application.
In developing a human computer interface it is necessary to generate many prototype interfaces, and to test them for ease of use with human operators. Because a large computer program lies at the heart of any sophisticated human-computer interface, it is very costly and time consuming to develop even one such interface, let alone a variety of prototypes which can be compared to each other to determine which one is preffered. For this reason, tools have been provided to aid in the specification and production of prototype human-computer interfaces.
Prior prototyping systems were unable to describe asynchronous events while a program was running in the high-level language used to create the prototypes. Typically, if asynchronous events, such as control of the mouse, had to be handled as part of the prototype, programmers were required to define those asynchronous events in a low-level programming language or by using a separate prototyping tool. In addition, if asynchronous events had to be linked to an item on the screen, the asynchronous event was linked to the X and Y coordinates of the item. This meant that if the item was moved to a new X and Y coordinates had to be specified to re-link the asynchronous event to the item.
For example, the BLOX (trademark of Rubel Software Inc.) interface development tool, uses state tables to describe states, changes of state ("transitions"), and actions for transitions. Each state table includes a test with one or more possible outcomes; each transition includes a possible action and entry to a new state. Table 1 below is a listing of BLOX code which would typically be used to draw line segments on a workstation in an interactive graphics application:
TABLE 1 ______________________________________ STATE Line --First --Point TEST Get --Point --Coordinates TRANSITION Drop --This --Point NEW STATE Restart --Routine --1 TRANSITION Record --First --Point NEW STATE Line --Second --Point STATE Line --Second --Point TEST Get --Point --Coordinates TRANSITION Drop --This --Point NEW STATE Restart --Routine --2 TRANSITION Draw --This --Line NEW STATE Line --First --Point ______________________________________
(Not shown above is the code for the tests GetPointCoordinates or the routine for the actions DropThisPoint, RecordFirstPoint, and DrawThis Line).
Using this state table, two states are identified and named GETTHELASTPOINT. The first state waits for mouse input to identify the line start point. Once received, the table tests to see if this point is within the screen work area (in this case, a window). Two transitions are then described for this test: one to enter a new state if the point is outside the work area, and a second to record the line start position and enter a new state to obtain the line end position. The second state waits for mouse input to identify the line end point and then tests to see if it is within the work area. Two more transitions are then described for this test: one to enter a new state if the point is outside the work area, and a second to draw the line and return to the initial state, thus restarting the cycle.
In prior art prototyping systems, the graphic elements consisted of a bitmap or a display list of graphic objects. The program used to execute the prototype could only interpret a bitmap or a display list, but not both.
Thus it is an object of the present invention to provide a process for producing prototypes of human-computer interfaces that avoids the limitations of the prior art processes discussed above.